home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Power Programmierung
/
Power-Programmierung (Tewi)(1994).iso
/
assemblr
/
library
/
screen
/
vblank
/
vblank1d.doc
< prev
Wrap
Text File
|
1990-10-05
|
4KB
|
84 lines
VBLANK VGA Screen Blanker
Uncopyrighted by
R. M. Utter, ProLogic
9598 Union Street
Scottsville, New York USA
14546
rather late in the 20th century
-------------------------------------------------------------------------------
In this litigious age, I feel obligated to include the following
Express Disclaimer Of Warranty And Liability.
VBLANK is a VGA screen blanker. It is _not_ a CGA, MCGA, EGA or any-other-GA
screen blanker. Its only mission is to blank the screen of a VGA monitor after
4+ minutes of keyboard inactivity, while occupying as little RAM as possible.
VBLANK has been in active and unfailing use on my system for many months. Should
you try it on your system only to have your monitor/video card/CPU/whatever
smoke or melt--well, I'll feel badly. I most certainly won't be liable. You do,
after all, have VBLANK's source code, and with it, fair warning of exactly how
the program works. It works rather well, I think. Having gotten that out of the
way...
-------------------------------------------------------------------------------
Herewith, version 1d of VBLANK.EXE, a small, VGA-only, screen blanker TSR. See
the end of this note for details about the trifling differences between 1d and
the previous version.
In response to problems reported by other users, this additional information,
not to mention another program, described below, is included.
VBLANK version 1d blanks and unblanks your VGA monitor via hardware.
Specifically, it sets or clears bit 5 of the VGA clocking mode register. Earlier
VBLANK versions used BIOS interrupts to accomplish the same task. But, this
change eliminates the possibility that VBLANK won't work with DOS/BIOS versions
before 3.3. (Why anyone would install VGA video on a system incapable of
supporting it properly is another question...)
VBLANK is a TSR (Terminate and Stay Resident) program. It relies on the
cooperation of other TSRs which intercept the DOS timer and keyboard interrupts
to work correctly. A crudely designed TSR loaded together with VBLANK can
entirely disable VBLANK operation. The rather obvious symptom is that the
screen never goes blank, no matter how long you wait.
BLANKVGA.EXE is intended to eliminate the possibility that VBLANK won't work on
your system due to a hardware incompatibility. Simply execute BLANKVGA. If your
VGA monitor goes blank for a period of about three seconds, then you can be sure
that VBLANK will work if another TSR doesn't interfere with it. If the screen
doesn't go blank, then your VGA card isn't totally VGA-compatible, and VBLANK
won't work.
Next, execute VBLANK from the DOS command line, then sit back and relax. If
BLANKVGA worked, then you can expect VBLANK to blank the screen about 4.5
minutes after you press <Enter>.
Assuming that all has gone well so far, feel free to add a line invoking VBLANK
to your AUTOEXEC.BAT, then reboot. If VBLANK now fails to blank the screen
after 4.5 minutes of k/b inactivity, then another TSR is interfering with its
operation. In this case, reorder the lines in AUTOEXEC.BAT which invoke TSRs.
The best approach, probably, is to make VBLANK the last TSR to execute. If this
doesn't work, then place VBLANK at the top of the list.
--------------------------------------------------------------------------------
Version 1d represents only the most minimal improvement over the previous
version. Two changes were made--
1] VBLANK's two ISRs now exit via a JMP to the saved interrupt vectors rather
than by the arcane method (PUSH the vector onto the stack, then RET) used
previously. Each ISR's processing now takes perhaps a microsecond less than
it did before.
2] The modification above made it possible to reduce VBLANK's RAM allocation by
one paragraph (16 bytes).
3] I discovered, to my horror, that my choice of INT 8, rather than INT 1CH,
as the source of the clock interrupt was a poor one. On my system, at least,
there were occasional instances where the DOS date wasn't updated at
midnight. While I don't know the root cause of the problem, switching to
INT 1CH seems to have cured it.
Direct comments and queries to me via netmail at 1:260/226.